fix(zod): generate string type for zod enums#1486
fix(zod): generate string type for zod enums#1486Sigmabrogz wants to merge 1 commit intomiddleapi:mainfrom
Conversation
dosubot
bot
added
the
size:S
📝 WalkthroughWalkthroughThe PR adds an explicit Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request resolves an issue where Zod enum types were not accurately represented in their generated JSON schemas. By explicitly adding the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request aims to fix an issue where Zod enums were missing the type: 'string' in the generated JSON schema. The changes for Zod v3 are correct. However, the implementation for Zod v4 introduces a critical issue by incorrectly assuming all enums are string-based, which will lead to incorrect schemas for numeric enums. I've provided a specific comment and a code suggestion to address this.
| case 'enum': { | ||
| const enum_ = schema as $ZodEnum | ||
| return [true, { enum: Object.values(enum_._zod.def.entries) }] | ||
| return [true, { type: 'string', enum: Object.values(enum_._zod.def.entries) }] |
There was a problem hiding this comment.
This change incorrectly assumes that all Zod enums are string-based. In Zod v4, z.enum() can also be used with numeric native enums. Hardcoding type: 'string' will produce an incorrect schema for numeric enums.
The type should be determined dynamically based on the enum values. It would also be beneficial to add a test case for a numeric enum to prevent future regressions.
return (() => {
const values = Object.values(enum_._zod.def.entries);
if (values.every((v) => typeof v === 'string')) {
return [true, { type: 'string', enum: values }];
}
if (values.every((v) => typeof v === 'number')) {
return [true, { type: 'number', enum: values }];
}
return [true, { enum: values }];
})()![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/zod/src/converter.ts (1)
343-353: Consider whetherZodNativeEnumshould also includetypefor string-only enums.The
ZodEnumcase now correctly emitstype: 'string', butZodNativeEnumat lines 349-352 still emits only{ enum: [...] }without a type. This is technically correct since TypeScript native enums can contain mixed types (strings and numbers), but for string-only native enums like the test caseExampleEnum, the schema won't includetype: 'string'.If intentional, this asymmetry between
z.enum()andz.nativeEnum()with string values may still cause downstream OpenAPI renderers to treat string-only native enums asany. Consider documenting this limitation or adding type inference based on enum value types in a follow-up.💡 Optional: Infer type for string-only native enums
case ZodFirstPartyTypeKind.ZodNativeEnum: { const schema_ = schema as ZodNativeEnum<EnumLike> + const values = Object.values(schema_._def.values) + const allStrings = values.every(v => typeof v === 'string') - return [true, { enum: Object.values(schema_._def.values) }] + return [true, allStrings ? { type: 'string', enum: values } : { enum: values }] }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/zod/src/converter.ts` around lines 343 - 353, The ZodNativeEnum branch in converter.ts returns only { enum: [...] } which omits a 'type' for string-only native enums; update the ZodNativeEnum handling in the converter (the switch case for ZodFirstPartyTypeKind.ZodNativeEnum / the schema_ variable of type ZodNativeEnum) to inspect Object.values(schema_._def.values) and, if every value is a string, return [true, { type: 'string', enum: values }], otherwise keep the existing behavior (return [true, { enum: values }]) so mixed-type enums remain unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@packages/zod/src/converter.ts`:
- Around line 343-353: The ZodNativeEnum branch in converter.ts returns only {
enum: [...] } which omits a 'type' for string-only native enums; update the
ZodNativeEnum handling in the converter (the switch case for
ZodFirstPartyTypeKind.ZodNativeEnum / the schema_ variable of type
ZodNativeEnum) to inspect Object.values(schema_._def.values) and, if every value
is a string, return [true, { type: 'string', enum: values }], otherwise keep the
existing behavior (return [true, { enum: values }]) so mixed-type enums remain
unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 911832ff-20c2-4c02-808f-9327fef9d8cc
📒 Files selected for processing (5)
packages/zod/src/converter.test.tspackages/zod/src/converter.tspackages/zod/src/zod4/converter.native.test.tspackages/zod/src/zod4/converter.structure.test.tspackages/zod/src/zod4/converter.ts
|
Closing this as a duplicate of #1478 which has been approved. |
1 participant
Fixes #1453
Zod enums (both in
z.enumand Zod 4'sz.enum) are inherently string literals. Previously,ZodToJsonSchemaConverteronly specified theenumarray without indicating thetype: 'string', causing downstream OpenAPI rendering tools (like Stoplight) to fallback to treating it asany. This PR explicitly addstype: 'string'.Summary by CodeRabbit